OpenEdge Development:<br />Progress Dynamics Basic Development The DataFields page

This page gives you the option of generating DataFields. DataFields are the Repository objects that represent individual application database fields. As discussed in Chapter 2, "Database Design Principles in Progress Dynamics," it is usually best to go ahead and generate DataFields when you import tables into the Repository. If you have done this, you do not need to check the Generate DataFields toggle box. If you have not already generated DataFields for your tables, then you should do it here. The DataFields page is shown in Figure 5–6.

Although DataFields are not SmartObjects in the traditional sense of being procedure-based objects with a procedure handle and super procedures to provide behavior and so forth, they are represented in the Repository as if they were SmartObjects. Each DataField has both an object record and a SmartObject record. Attribute values are associated with each DataField SmartObject record as for any SmartObject. When you generate DataFields for the fields in your database, these attributes are assigned for each field:

ObjectName (CHR) — The ObjectName of a DataField is its TableName and FieldName, separated by a dot.

DatabaseName (CHR) — The logical database name of the field’s table.

TableName (CHR) — The table containing the field.

FieldName (CHR) — The unqualified field name.

Label (CHR) — The field format, derived from the database schema.

ColumnLabel (CHR) — The field’s Column-Label from the schema.

Format (CHR) — The field’s Format, also from the schema.

Help (CHR) — The field’s Help string, if any, from the schema.

Mandatory (LOG) — Whether the field is marked as mandatory or not.

FieldOrder (INT) — This is, by default, the value of the _Order field for the database field. It could be modified in an SDO instance to reflect a change in the ordering of fields.

VisualizationType (CHR) — This is the View-As property of the field.

InitialValue (CHR) — The Initial attribute of the field in the schema.

DataType (CHR) — The field’s data type.

Any SmartObject has attribute values for its master object, which are the defaults defined for the object wherever you use it. You can then extend or override these values when you use the object in a particular context. For a SmartObject, this would be, for example, when you use an SDO, browser, or viewer in a particular window. The object takes on additional attributes, such as its position, which do not apply to the master object, and you can override other attributes (for example, which fields are enabled) for this instance of the object.

Though not a true SmartObject, the DataField also has master and instance attributes. The master attributes are those derived from the database schema. These master attributes form the basis of any use of the field in a field container object. In the case of a static SDO, the field list is defined within the SDO procedure, and the attributes of each field are compiled into that procedure from the include file that defines the SDO’s temp-table. However, to support dynamic SDOs, the field records and their attributes as defined in the Repository make it possible to generate the SDO out of the Repository as a dynamic object. For this purpose, instance attributes are generated for each occurrence of a field in an SDO. This includes additional attributes, such as Enabled, to flag whether the field is updateable or not in this SDO. Having these DataFields and their master and instance attributes in the Repository makes it straightforward for you to convert static SDOs to dynamic ones.

In addition, instance attributes are generated for each occurrence of a field in a viewer. These attributes record its position, size, and other characteristics. Every Progress widget attribute for a field can be assigned for a field in a viewer. The dynamic viewer, as a data-driven object, depends on these field definitions and attributes. The static viewer does not, but as with the SDO, having the fields and attributes in place will simplify converting static viewers to dynamic ones at a later date, to reduce r-code size and simplify application maintenance.